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Posing.
Okay.
Okay.
You have a fairly large organization, you got a building with multiple floors, and
they are all connected, and you don't know everybody around them, and I come around saying,
listen, I'm the network administrator, there seems to be something wrong with your machine.
Sit down, play with the machine, have a floppy with me, install a backdoor or trojan, go
away.
Okay.
It could happen, it does happen.
If you don't think posing is too technical, you know, you could term it as human spoofing.
Okay, I've walked in as someone else.
Dumpster diving, everybody's heard about, you know, throw stuff away.
The last point is really the most important.
You have a disgruntled employee and you've got a bad enemy, okay,
because the guy is sitting inside of your organization.
Most people protect their organization with a fence outside, an electronic or digital fence.
What do you do inside?
Very, very few people take enough security precautions within an organization.
And 65% of the attacks happen from inside was based on a study which happened maybe one and a half years ago.
I actually think the number is probably higher.
Maybe 75-80% of the attacks originate because of inside information.
Okay, now to the slightly more interesting stuff.
The programmable dangers today include this entire list that is out there,
you know, starting from viruses and backdoors and denial of service attacks
and...
sniffing and spoofing.
Okay.
Viruses and worms.
My opinion, this is the biggest threat and the worst pain in the butt for most corporations.
Very simple.
To use or...
I mean, I don't need to get into your machine when you are online,
try and get the root password and then do a rm-rf slash or...
l-star-dot-star-from-slash.
That's complex.
What if I could simply send you an email which contained a piece of malicious code which did exactly that?
Okay.
The mail comes to you from someone you know.
There's an attachment on it.
You click it.
Or there's a program which, you know, kind of is supposed to do something else.
You click on it.
And it actually launches a piece of virus which goes and sits in your boot sector
and toasts your hard disk.
So, you have an organization now
with, let's say,
three, four hundred people.
And you know how the internet is, right?
You kind of keep forwarding jokes and you forward pictures and you forward stuff to each other.
So, something interesting comes into this organization.
And before you know it, everybody else has got it.
Now, why is this so dangerous?
Simply because port 25, your mail server port,
or the machine that's going to pick up mail from your POP account,
is really going to allow connections through to 110 to 25.
You download stuff off the web.
Most firewalls would allow connections to port 80.
So, it's really a very loose fence that lies over there.
And therein lies the danger.
You know, people get stuff down before you know it.
And it's so easy to write viruses these days.
I mean, you've got do-it-yourself kits.
You've got Microsoft.
It's easy.
Viruses is actually a super specialized shopping in itself.
I don't know much about it.
I'm not very interested in it.
So, we'll go ahead to the next one.
Excuse me.
Okay, Trojans.
Everybody heard of Trojans?
Trojan horse programs?
Yes? No?
Wonderful.
Pretends to do something useful.
And, I mean, the slide is self-explanatory.
I remember the first time I did this about ten years ago
during post-graduation of software technology,
I wrote a login emulator into the mainframe.
And it was unbelievable the number of passwords one picked up.
More importantly, all the guys, or let's say 80% of the guys,
you'd know which woman they were hot after
simply because that was the password they'd selected.
So, the next time you go and login into your system,
and it comes back with, you know, login failure and the login prompt comes again,
ask yourself, listen, was that something else?
Or was that me making a typo?
Okay.
What is a denial of service attack?
Anything that prevents the normal function of services,
servers, networks,
hosts,
it cuts you away from resources,
can be termed as a DOS.
And DOS in principle is not really new.
In the olden days where computing power was still looked up to,
it was still precious,
where RAM and CPU was valuable,
these things have existed since that time.
So, for example, if I wrote a small script which kind of said,
while true,
make directory A,
change directory into A,
and repeat the loop.
Okay, what would happen?
It would recursively go all the way in.
Okay, now let's say on a Unix system,
you're limited by the fact that you're a particular user
and you have constraints on what you can use up.
But let's say if it was run as root,
or in the olden days where limits were not imposed so tightly,
you would run out of inodes on the system.
Okay.
Every available inode where you can hook on a directory or a file
would be taken up,
and in effect you've done a DOS on the particular machine.
The DOS that we are interested in today is a little more advanced.
I'm interested in being able to sit here
and launch something which kind of goes and does something on a server
which is probably sitting in Iceland or Alaska or something,
or maybe the other way around.
Okay.
Now there are multiple ways in which
you can execute denial of service attacks.
One of them is called, let's call it magic packets.
The principle here is to send a small,
maybe even a single malformed packet to your target host.
Now the malformed packet is what causes the magic to happen.
Okay.
This packet will really break accepted de facto network links.
So for example, the packet could be oversized.
If the packet is a TCP packet,
there are various control flags that a TCP packet has.
These control flags would signify what stage of the connection
this entire connection is in itself.
Am I making a connection?
Am I transmitting?
Am I acknowledging?
Now if I could set up flags which were not expected by the remote system,
that could be a problem.
Injecting out of sequence packets.
Okay.
Now the reason why this particular attack would succeed
is because the TCP IP stack on the target machine
is not stable or robust enough to handle exceptional cases.
Okay.
Anybody heard of WinUK?
It's a very old thing.
How many heard of WinUK?
Yeah.
Not too many.
Okay.
When Windows 95 actually popped up,
you know, it was a nice, good, clean,
graphical user interface.
That's when this thing was formulated.
The way this attack worked was
it targeted your Windows machine on port 139,
which was the net IO port.
It sent the packet with the OOB,
the out-of-band flag marked as on.
The remote machine didn't know how to handle it,
and thuck.
You know?
So the story is like if you're on ISE and you're chatting with someone
and you kind of get into an online virtual argument,
and,
all of a sudden you see a screen go blue,
the blue screen of death,
and your machines crash,
it's probably,
or was probably,
a WinUK packet which was generated.
The reason the machine crashed,
your Microsoft OS went down was,
anybody?
Simple.
Whenever a Microsoft program doesn't know what to do,
it does what all good Microsoft programs do,
but it crashes.
Okay?
So,
and the story here is that
the minute this thing happened,
Microsoft was informed,
they released a patch,
and it is ridiculous as the story goes.
Okay.
The patch was like this.
If I sent you a WinUK packet,
the payload of the packet contained a particular string.
If I recall correctly,
it was BEWM.
So what Microsoft did in all its wisdom,
it filtered anything that came to port 139,
had the OOB flag on,
and had a payload of BEWM.
Okay?
It silently ignored that.
It was a matter of a few hours before WinUK 2 happened,
which completely randomized the payload,
put in various other things,
and then Microsoft was forced to actually release a real patch.
But why WinUK is so important is
it became the first piece of software that used magic packets
and was distributed widely over the world.
I mean, you had variations where
I could set up one piece of,
one attachment,
one tackle,
shooting to various machines and stuff like that.
It was fairly crazy.
Okay.
Another style of DOS is a network saturation attack.
As the name implies,
you flood a network with so much of traffic
that machines and routers on that network
simply can't handle it anymore.
What happens is they go into
high strain trying to, you know,
route and process the packets as they're coming in.
And all these packets,
because they're illegitimate,
are actually taking away resources,
bandwidth as well as CPU power.
As a result, what happens?
Real applications like web and email
and FTP and stuff like that
that legitimate users might want to use
also get affected.
So a network saturation attack actually affects
a large number of people.
You know, I might be wanting to target that particular thing
for one particular individual or organization,
but anybody that's using that network is going to get affected.
All networks which are enroute,
the attacker and the victim would also get affected
because of a huge amount of traffic.
Okay.
There are other ways in which you can do DOS.
It's really dependent on your imagination and innovation
and how much you know of the protocols.
Everybody heard of ping?
You ping a machine to see if it's alive or not.
Now, what happens
if I send out a ping packet
as a broadcast ping
to multiple machines on my subnet, for example?
Each of these machines is going to get a ping packet
and each of these machines is going to reply back to me.
So instead of pinging one machine,
I've pinged multiple
and I've got multiple replies back.
Okay.
So where is the trick here?
What I could do is
I don't like him.
He's my, whatever, neighbor,
and I know he sits here.
I know his IP address.
I spoof a ping
to a huge network,
with his IP address.
Okay.
So what happens is
all the machines that receive that ping request
actually send a response back
and this guy's machine is hit with that.
Okay.
So things like that.
Similarly, SYN flooding.
You know, you set up so many connections to a machine
that the machine is
every machine's got a finite capacity for accepting connections.
I mean, it's configured.
Now, once you exceed that,
any other connection that happens to come to the machine
is going to get dropped.
We'll look at SYN flooding a little later.
Similarly, connection killing and hijacking.
You have a running connection between two machines.
I can actually try and break it.
We'll look at both of these.
Okay.
They say you can't get too much of a good thing.
So when you're doing a DOS all by yourself,
the next logical step is to have a distributed denial of service
where the principle is simple.
It says united, we deny.
A plain DOS will have a single point of launch.
Okay.
So if it is identified that there is a DOS happening
from this particular machine off this network,
it's easy to filter out those packets.
Authorities which actually handle the links and route
can also start dropping those packets.
But in a DDoS, you have several launch points.
So the typical accepted method is
you compromise a huge number of machines
based on bugs that may be there.
On every compromise method,
you set up a DOS client.
The DOS client is triggered eventually with a DOS server.
So what happens is at one point in time,
I use my DDoS server to activate thousands of DDoS clients,
all of which can then target a particular network
or a host or whatever it is that you need to do.
Okay.
No.
The benefits with a question mark
depends on which side of the fence you are sitting.
Okay.
If you're the guy who's doing the DDoS,
then these are benefits.
You can now, I mean,
disabling a few individual machines
is not going to stop the attack.
You can now target larger networks.
About, I think, three years ago,
when Netscape Corporation was still up and alive
and, you know, really big,
I remember reading somewhere that the total bandwidth
that went into the Netscape Corporation's office
was greater than the entire international bandwidth
that India had.
Okay.
So in case I needed to,
I mean, I was a Microsoft fan
and I wanted to knock off Netscape,
there was no way I could do anything about it
using a DOS.
But a DDoS may have been successful.
We have had incidents where Yahoo, eBay, and stuff,
big portals like that have been knocked off.
Okay.
Am I going too fast?
Is the speed okay?
Wonderful.
The next thing we're looking at is sniffing.
Most corporate networks, okay,
are broadcast networks,
which means when machines are talking to each other,
there is a chance,
I mean, everybody actually gets to see the broadcast.
In the olden days,
where you had physical cables connecting
and you didn't have hubs and switches,
it was truly broadcast.
I mean, I could see and hear everything
that happened on that particular network.
Today, it's slightly different.
Switches make it a little more difficult to sniff,
but if they're non-configured,
they can also be compromised,
and you can sniff on it.
The way it works is you have a sniffer program
which puts your network interface card
into something known as promiscuous mode.
Normally, what happens is your machine is going to accept packets
that are designed only for it.
The minute it goes into promiscuous mode,
it's going to accept any packet that travels past it,
which is all the broadcast packets.
The card will now accept the packet.
It will push it up to the sniffer program,
and the sniffer program,
then decides and chooses packets
that are of interest to it.
What do you think we could use a sniffer for?
Most obvious applications?
Username and password.
Username and password.
What else?
Email traffic.
Email traffic.
What else?
Credit card numbers.
Credit card numbers.
Okay.
All of you guys are on this negative trip.
How about analyzing network traffic?
Okay.
The good guys really call the sniffer a network analyzer.
I mean, but...
Okay.
Characteristics are it's passive.
You're just listening.
It's not really intruding.
So it's fairly difficult to detect it.
These are the users we talked about.
Okay.
If I log every byte that travels on the wire,
where my machine is,
in effect, it's a remote key logger.
And the last two points, really.
That's true.
It helps to paint a very accurate picture
of the network traffic.
Okay.
Often the only indications you'll have
is when you see that hard disk light,
you know, beaming and beeping frantically,
and the CPU load going fairly high,
because now this guy's accepting and processing all packets.
So it has to write them somewhere
if you're going to capture them,
it has to process them,
so the CPU is very active.
Somebody might say,
listen, what if I run a PS?
You know, if I get a...
Can I get a process listing?
Yes, you can.
But if the system has been compromised,
these programs would have been trojaned and replaced.
So you run a PSAX,
and you would actually see all the processes
minus the sniffer.
You run an ifconfig,
which actually checks the status
of your network interface card,
and you would see that it is not in promiscuous mode,
whereas it really is.
Okay.
The first one is something that we've already
talked about in the first slide, human spoofing.
But in reality, it applies into the digital world also.
The minute you pretend to be someone else,
you've gone into what is termed as a spoofing attack.
There are various types.
IP, DNS, web, and...
Okay.
So what is IP spoofing, really?
You forge the source IP of your first packet,
of your connection packet,
of the packet that's actually going to talk to people,
with an IP address that is not yours,
and you've spoofed,
or you've pretended to be someone else.
The typical method in which a hacker or a cracker
might use this is to use,
they use a denial of service attack
to knock a particular machine off the network
if it's not already off.
I mean, if there's a machine off and you know
that this machine's not alive
and it cannot respond to packets,
then you don't have to use a DOS,
but otherwise you use a DOS, knock a machine off.
You masquerade as the machine,
talk to the target host.
Because you're masquerading as the machine,
if there is a trust relationship between these two machines,
between the target and the machine which is now knocked off,
you can exploit that trust relationship.
A lot of these concepts and ideas really work together in harmony
to create a completely successful attack.
So when we talk of IP spoofing,
I can use IP spoofing for SYN flooding
and use that as a denial of service attack.
The idea is, you have two machines A and B.
This thing is termed as non-blind
simply because it happens to be in the subnet.
So I can actually see packets travelling between the two.
Let's assume I knock A off the network.
A can no longer respond.
I've used a DOS or the machine is off
or I know someone's not there.
That machine is off.
Now I want to target B.
What I really do is I send it packets
impersonating as machine A.
Now really what's going to happen is every packet,
every connection that is initiated
is going to go with the SYN flag on.
In my packet, it says I want to
this is my initial packet.
I want to synchronize the connection with you.
B gets that connection.
How many people have heard of the three-way handshake?
TCP three-way handshake?
So it's really exploiting the TCP three-way handshake.
A packet supposed to have come from A
goes to B with a SYN flag on.
B accepts the connection.
It responds back with its own packet
saying that I'm also going to synchronize.
This is my initial sequence number.
Switches on his SYN flag.
And he acknowledges the first packet from A.
Now in reality, A is not alive.
So this packet has gone back to A.
If A were alive, A would respond with its own acknowledgement.
One, two, three.
The three-way handshake would have taken place
and that would be the start of the connection.
Now since A is not on,
B is going to go into a timeout stage.
Now while B is waiting for an acknowledgement to come,
he's actually got a data
a data buffer in memory
which logs the state of all connections
that are still pending,
all connections that have not been picked up by the application.
Now this queue, which we will call the backlog,
is of finite size.
If I can send enough SYN connections
and fill up this queue,
B is actually going to be waiting in that particular state
and not accepting any more connections
until all of them timeout.
Now eventually they will timeout
and B will start accepting connections,
but it's trivial for me to keep initiating
new connections every few seconds.
Okay?
So this is called a SYN flooding attack.
B is completely knocked off.
Okay, this is the problem.
One second.
Okay.
You can see that A has been knocked off.
Host X impersonates A.
It causes the backlog of B to be exceeded
and B won't accept any more connections.
So you've just done a DOS
using SYN flooding and IP spoofing.
Okay.
Now you can use the same principle
to actually kill an active connection
between two machines.
You know that TCP maintains its so-called reliability
based on sequence numbers and acknowledgments
between an active connection.
The sequence numbers actually allow machines
to put out-of-order information back into order,
to discard duplicates,
to make sure the connection is being established
with a three-way handshake,
breaking with a four-way exchange,
and so on and so forth.
If I can now compute the sequence and acknowledgments
of packets as they travel past my machine,
so I sniff the packets,
I compute the sequence numbers that are happening,
and let's say that I want to now terminate this connection.
I can create a packet with the reset flag on,
the RST flag.
The RST flag, when it is received,
only needs to have the correct sequence number.
Okay?
The machine that receives this flag,
for that machine,
it's a signal to tear down the connection immediately.
So you have A and B running a connection
which is live in real time.
I'm sniffing the packets as they go through.
I compute the sequence number.
I create a fresh packet with the expected sequence number
for, let's say, B.
I set the reset flag to on,
and I inject it onto the network.
Now, if your computation is correct,
if the timing is correct,
if nothing really goes wrong,
B is going to accept this.
It's going to see the reset flag down.
It's going to tear down that connection instantly.
All of the packets that come from A into B
are simply going to be discarded
because they will be assumed as bogus.
In fact, we might even send a reset back.
Okay?
So we will call this an evil reset flag.
Now, you could do the same thing
using the fin flag,
where when a machine legitimately wants
to shut down a connection,
it actually switches the fin on,
sends the packet to the remote machine.
The remote machine acknowledges it,
and when he is through with whatever he wants to do,
he sends his own fin back.
So just the way a three-way handshake sets up a connection,
a four-way transaction breaks the connection.
Okay?
The beauty of using a fin instead of a reset is
you will always get an acknowledgement back
from the remote guy.
So if I've injected a fin inside,
and for some reason I don't get an acknowledgement,
I don't sniff the acknowledgement from B,
I know something went wrong,
and I can attempt to do that again.
But the principle is the same.
Okay, now you take this one step higher logically.
If I can kill a connection,
why can't I hijack a connection?
So let's assume you've telneted into a particular machine.
You're running a shell over there.
Someone from A has telneted into B.
Why can't I, you know,
get in and actually take over the connection
and pretend to be A?
You can.
The way to do it here is
to compute the sequence number and acknowledgement.
Yeah?
So as a result, what will happen is
A will continue transmitting what it had to transmit,
but since B has updated his counter,
he's going to treat those packets as bogus packets,
which leaves A completely confused.
Your packets are traveling to B.
Your packets have got the correct sequence numbers.
TCP only cares about the sequence numbers.
That's how it's maintaining reliability.
And in effect, you have actually taken over that connection.
So if this were a shell that were running there,
you could simply install a backdoor program,
or if the R commands have been enabled,
you could set up a .ros file with a plus plus inside it,
break the connection.
The guy who's sitting on A will probably think,
you know, I mean, if he's dialed in, for example,
or it's a bad connection or the program's hung,
normally people kind of break it
and just log in again.
So, I mean, real-life breaks do happen.
Just because the thing happens to break
doesn't mean you've been hijacked,
but these are ways in which people could take over a running connection.
Any particular questions so far?
Does that mean everybody's understanding,
or does that mean you're not understanding?
I'm not going to ask that one.
Okay.
Okay, this one is, as you can see,
it's based on a technical report at Princeton University,
which happened in 1997.
But I believe it is so applicable in real life,
the thoughts and the principles,
that this is something that I would be very happy to share with you.
The idea is,
the idea in web spoofing is
that the attacker actually creates a shadow copy of the web.
Okay?
And if you are a victim,
when you are surfing,
you actually believe you're surfing the real World Wide Web,
whereas you are actually surfing the web that has been set up by the attacker.
Okay, I can almost say the first question,
somebody says,
hey, you mean somebody's going to copy the entire World Wide Web?
No, it's not like that.
We will look at what really happens here.
If you look at the point,
the second point,
you know, it's applicable for all spoofing.
Spoofing is like a con game.
You set up an environment which is convincing,
but simply because you're doing spoofing,
it's really a false environment.
And based on how well you set up that environment,
you're going to affect the behavior of the victim,
completely based on contextual cues.
Okay.
Now, if this is successful,
what does it do?
What really happens?
This will influence all security-relevant decisions
that the victim is going to make.
When I say security-relevant,
what am I talking about?
I'm talking about names and passwords.
You might want to log into a service.
You might give credit card information.
You might accept documents.
And we've already seen the dangers of,
you know, let's say viruses or malicious programs
being embedded in documents.
You might accept the accuracy of information.
So if you're trading,
and you actually are looking at a website which says
the shares or the, you know,
the prices of, you know, whatever,
VA Linux or Microsoft have gone up or down,
and you base decisions based on that,
these are all security-relevant decisions.
And all of these will be affected
in this kind of an attack.
So why does it work?
Okay, this works because the attacker
has very intelligently used context.
When you're surfing the web,
most experienced servers behave like drivers.
Okay?
So you're driving the road.
You're really thinking,
I need to press the, okay,
most of you guys drive automatic transmission,
so I don't need to press, you know,
the clutch now or the brake now and stuff like that.
Somebody runs across.
You jam it.
It's all automatic.
Now, exactly in the same fashion,
you go to a website or you see a logo
that materializes in front of you,
and the mind has subconsciously accepted
that you're connected to the server you want to connect.
Okay, so the appearance of the object,
the name of the object,
manual.doc.
Is manual.doc the manual
for the software that you have just downloaded,
or is it something else altogether?
For all you know, it might be an executable.
Finally, the timing of events.
If I fed in www.mybank.com
and I get a pop-up which says name and password,
simply because of the timing of events,
I am going to enter the name and the password
that is my login into this particular bank.
Now, if all of these happen,
what are the dangers that are alive?
Surveillance, obviously.
Tampering.
That brand new Dell or whatever that you order,
if I could change the delivery address to mine,
then you've paid for my machine.
And quantity numbers and product numbers
and so on and so forth,
anything can take place.
Okay.
Now, let's look at how it really works.
These are the principles on which
this particular spoofing attack will work.
It's termed as a man-in-the-middle attack.
I'm not sexist.
I didn't coin this phrase.
It could be a woman-in-the-middle attack.
But the idea is here is the victim,
here is the desired web URL,
and in the middle is the attacker.
So it's a man-in-the-middle attack between a client server.
It works on URL rewriting.
So if you go to www.hotmail.com,
the page is fetched.
The URL on that page is,
all URLs on that page are rewritten to,
let's say, www.attacker.org
slash www.microsoft.com, whatever else.
So every subsequent click on a link
will actually go to the attacker's machine first.
From there, it will go out to the real web.
And then information would come back to you
after having been tampered.
Now, this would work completely with forms
because forms are so closely integrated
with the web protocols.
You might even see a secure connection indicator light up.
Let's say Hotmail now gives you a secure connection
into your email box.
Now, sure, you have a secure connection.
The only difference is your secure connection
is between your machine and the attacker's machine.
It's not between you and Hotmail.
It's between you and the attacker,
and you have the secure connection, the lock, going up.
So how would this attack actually work?
How would you start?
You know, how would you begin it?
You would need to have a false link
on some web page.
You could transmit a false link using webmail
where you've got HTML enabled.
Or you could even have a poisoned search engine.
For example, a search engine has actually indexed a page
which seems to contain good information
but really serves as a starting point
for this kind of an attack.
Okay.
Okay.
Let's assume the attack is on.
The way I've described it so far is fairly effective.
Okay?
It would work.
It would be able to take your request.
It would be able to pull out your request from the web,
translate each of the URLs,
and feed that back to you.
But the attack, the way we've talked about,
is not perfect.
Can anybody tell me what...
There are still contextual cues that will tell the victim
he or she is being attacked.
Things like...
Sorry.
Malformed URL, yes.
What else?
Doesn't anybody surf?
You guys are experienced surfers.
Okay.
It's simple.
Every time you move your cursor over a link,
when it turns into a hand,
you have the status line at the bottom
that would reflect the link.
So you would actually see www.attacker.org
slash the real server.
Every time you click on a link,
for a brief instant,
as the browser makes a connection,
to the remote machine,
you will actually see connecting to www.attacker.org.
Now these are things which the victim could see
and realize something is going wrong.
So as an attacker, what do you do?
You fall back on the premise that
the major browser makers have made life comfortable for you.
They've let the browser be very customizable.
So you embed a piece of JavaScript into your page.
JavaScript is allowed to write to the status line.
So this piece of JavaScript is now going to get rid of
both of these problems.
Every time I hover my cursor over a link,
it's not going to show www.attacker.org
slash whatever.
It's going to show me what I really expect to see.
Every time I click the link,
although the browser is connecting to my machine,
to the attacker's machine,
it actually shows a connection to the target
that you really want to reach.
So you've overcome obstacle number one.
Any other things you can think of
that might be a problem?
That might give the victim an indication
of the attack in progress?
There's something even easier than that.
Yeah?
I'm sorry.
I can't hear you.
Right.
Sure.
I'll come to SSL in a moment.
Yeah.
Okay.
Okay.
Once you are connected to a particular site,
if you realize the top bar,
the location line,
actually shows the page that you are on.
You can see that the location line
in this case,
even though the status line has not given me any clues,
will actually show me that I am at attacker.org
slash whatever else.
Once again, JavaScript comes to the rescue.
You can actually replace the location line completely.
And the people who did this study in Princeton,
who did this report,
they actually made a working model of this thing.
So the location line also reflected the correct URL.
The next question most people ask is,
listen, what happens if I go and feed in information
into the location line?
Again, very valid.
The JavaScript will allow me to accept info.
So I say www.hotmail.com
simply because we're talking Hotmail.
Internally, this guy will make a connection via attacker.org.
So you've suddenly eliminated all visual trace.
Okay.
There is one more thing that you could do,
as the gentleman here mentioned.
What happens if I view the document source?
The document source is going to show me the presence
of both of these pieces of JavaScript.
And immediately, the attack is known.
My question is, in real life,
how many of you view the document source
every time you visit a website?
Not too many.
Let's assume for a moment that all of us got paranoid
when we went away after this presentation
and we started viewing the document source
of every page we visited for the next three days.
For the moment, hypothetically.
Now, it would be very clear that there's something going wrong here.
Okay?
Once again,
JavaScript is your friend.
What these guys did was,
they replaced the menu button on top,
the menu drop-down,
which shows view document source,
and they embedded their own stuff.
So when you went and actually clicked on view document source,
this guy showed you the real page that had come from the web,
minus the attacker URL rewritten links,
and the illusion was complete.
Okay?
There was no way to get out of it.
Okay?
So this is completing the illusion.
This encapsulates the points we just spoke about.
The remedies that were suggested are things like,
you know,
disable JavaScript,
be very alert,
look at the URL lines,
look at the location lines.
They recommended software enhancements.
So when you're doing an SSL kind of connect,
instead of simply having an indicator
which kind of,
you know,
you have a lock which is on,
how about if that guy actually said,
I am connected to Microsoft.com,
because your information exchange
would have that kind of information.
I'm sure.
That's true.
I completely agree.
See, it's a,
unfortunately there are these two things,
the good and the evil.
Sorry.
But you have a lot of good with JavaScript.
I understand that.
All I'm saying is that the same tool
can be utilized for evil also.
So somewhere it's a fine line,
somewhere you kind of decide,
you know.
I mean,
if you know nobody's really going to target your grandmom
and there's really nothing tough for them,
you keep it at evil.
Yeah.
I'm not very sure.
Java would be more difficult to do
simply because of the sandbox rules.
For example,
on Linux now,
Conqueror lets you specify,
per site enabling of,
let's say I could enable JavaScript on a per site basis.
I could enable Java on a per URL basis.
So if you know you are connecting to a trusted source,
you may choose to enable it over there.
But the recommendation would be to,
by default, disable.
And then enable only small.
Okay, what are normal regular countermeasures?
Most of these things that we spoke about
actually arise out of ignorance.
Pure and simple ignorance.
So user awareness is very critical.
In an organization,
you need to set up policies.
You know,
things you put down on paper would say,
I will let my employees serve only at this time.
I will let these sites be available.
I will allow email to happen
or I won't allow email to happen.
Put up things like password tighteners.
So you won't kind of simply put in girlfriend names,
pet names,
and so on and so forth.
Set up expiry dates.
Completely avoid clear text programs.
If you're doing any kind of terminal work,
you're logging into systems,
throw away telnet.
Okay?
Use SSH.
Bypass FTP.
Okay, now the next three or four slides,
really I'm not sure if we have time to get into
because I've just been told I've got something like
two and a half minutes left.
But my next four or five slides actually talked a little bit
about firewalls,
what kind of things you can apply.
For those of you who are interested,
if you send me an email,
I'll try and make sure the presentation
is available online.
Next two minutes,
should we just take up questions,
if any?
Yes.
Right.
Okay.
When I was talking sniffing,
I actually meant being able to read the low-level packets.
So it's not so much about spoofing using email.
On a switched network,
what would happen is the device,
the physical device is a little more intelligent.
So even if you've got 50 machines connected,
it would route information only between the two required machines.
Right?
Which is why it becomes difficult to sniff on a switched network.
But I believe you can do things like ARP spoofing.
So a level lower than your IP level, for example.
So every time a packet is sent out on the Ethernet,
he needs to figure out the hardware address
of the machine to write to.
Now, there are programs and there are ways.
I'm not really an expert to that level,
but there are ways in which I can...
When an ARP request is sent out,
the response that comes back directs the packet
to come to my machine.
Now, if I am smart,
what I will do is I will make sure my machine
becomes a man-in-the-middle kind of thing.
So I will relay stuff.
So for all practical purposes,
A is talking to B.
Okay?
You are doing stuff.
Everything is going through my machine.
Simply because I have been able to ARP spoof
that particular connection.
Anything else?
Yeah?
When you were talking about IP spoofing,
you said you could do the sequence number.
How do you do the sequence number?
Okay.
There are really, again,
that's getting to be more and more difficult,
but there are many ways of doing it.
Normally, it was well accepted that the stack,
when machines actually came up,
they kind of started with one, okay?
Right in the beginning.
And every second,
the counter got incremented by 128,000.
For every connect,
you got an increment of 64,000.
Now, really what happens is
when you're trying to predict sequence numbers,
you would try and make legitimate connections
to a machine, multiple connections.
So you kind of compute three, four things.
One is you get to see what the ISN is,
the initial sequence number.
You kind of log that.
You send three or four connections.
You get to see how the increment is happening.
Then you also figure out how much time
it's taking your packet to come back,
the round-trip time.
So you need to know roughly
how much time it takes to reach there,
because with every packet reaching,
your counter's going up by 64K.
Okay?
Based on these kind of things,
you initiate a connection,
and hopefully someone else has not gotten before that,
where you can predict the sequence number.
Okay.
These are getting more and more difficult
because, logically,
the next steps were to randomize
the way sequence numbers were happening.
So if you run NMAP, for example,
which is a port scanner and OS detector
on a lot of machines,
it comes back saying,
Listen, I've detected Windows here,
and it's trivial.
Your sequence number prediction is trivial.
Or if it's Linux, it says,
Bad stuff.
Good luck to you, friend.
You know?
Things like that.
So it's...
Yeah?
Is there anywhere on the website
where you can check the cell frequency?
I don't think so.
I don't think so.
I mean, let's look at it.
If the packet never reaches you,
you don't know that you are
being denied information
or requests that are coming to you.
Sure, you might notice that
my web traffic has gone down.
But there could be multiple reasons for that.
I mean, for example,
if I did a denial of service attack
against a particular site,
let's assume there's an ISP
who's got lots of clients over there.
You're targeting one particular client.
Simply because you are creating
so much of network saturation
and you're making life miserable
for all his clients,
what will the ISP do?
He'll simply filter out any packets
that's coming to the target site.
In effect, what has he done?
He's helped the attacker.
I mean, he's done
what the attacker was trying to do
much more effectively.
He just pulled the plug on that guy.
Okay?
So it's...
Yeah?
Sir?
Yes, please.
Frankly, I haven't used commercial firewalls.
Most of my work is with packet filtering
on Linux,
so I really am not the right person
to give you information on that.
Sorry.
Yeah?
With the episode of compromise,
my information first is on the site
where I would show up in your statements, right?
Sure it would.
I'm sure.
But it's like saying
you're taking corrective action
after the event has taken place,
after something's happened.
At that point of time,
the amount of loss that has taken place
and the amount of negative that has happened
is something which you probably can't reverse.
Isn't it?
Sure.
Now we're getting into business policies,
again, which would vary
from different parts of the world.
My premise is
I've gone and deleted all the information
on your server.
Doesn't help.
I'll give you my last...
Just in case anybody needs to read
or write to me.
Okay.
That's my email address.
In case somebody needs to write and ask,
I'd be happy to...
Yeah?
Sorry?
1997 is when the report came out,
and they said at that point of time
it affected both Microsoft Internet Explorer
as well as Netscape.
I'm not sure of current status.
But the idea of...
Sorry?
.
No.
They actually said
we have a working model
which you've demonstrated,
but we're not going to release it to the web.
But it was pure JavaScript.
.
They actually replaced the real menu
with their own.
So when you clicked on it,
internally the intelligence was built in
to actually get the real page
and show it to you.
.
Yes.
Yes.
Yes.
Yes.
Okay.
Thanks.
I'll stop here.
